InfoMagic Standards 1994 January/InfoMagic Standards - January 1994.iso/inet/ietf/ucp/90may.min

Text File | 1993-02-17 | 12KB | 344 lines

CURRENT_MEETING_REPORT_



Reported by Ken England/ Boston University and Karen Roubicek/ BBN

Connectivity Tool Demonstrations

Metin Feridun made a brief announcement of demonstrations of the
``Connectivity Tool'' that he has been working on.  The CT is designed
to present a network detective of modest skills with a suite of analysis
tools and built-in technique to make the problem of tracking down
internet connectivity easier.

Last Meeting

At the last (first) meeting of UCP-WG, Craig Partridge, Elise Gerich,
and Karen Bowers each made presentation of a point of view on modeling
the operations of the Internet.  Unfortunately, none of these worthy
thinkers was able to attend the IETF this time, so the host had to make
due with unworthy re-presentations of these ideas and copious reference
to notes from postings that these thinkers had made to the ucp list,
prior to this meeting.  Perhaps the original ideas came across anyway.

Craig Partridge's Model

Craig Partridge's model was reviewed.  Karen Roubicek coined the term
``UCP Central'' to denote the national ``center'' with an 800 number,
and this term was extended to include elements of following models.

Craig identified at least four elements of an architecture:


   o UCP Central (the 800 number service)
   o Site Entity
   o A User (of this system under study)
   o A Regional Entity (tentatively put forth for study)


Elise Gerich's Model

Elise identified some structure within the ``UCP Central Entity'' [note
that terminology is deliberately vague, in order to avoid excessive
connotative baggage -kwe]

In addition to recognizing Site and User Entities, like Craig's model,
Elise put some structure to the UCP Central Entity, by postulating:


   o National Center (we called it UCP Central)
   o (Six) Regional Centers

                                   1






and corresponding structure.

Karen Bowers' Model

Unfortunately for us, Karen has left the Internet community and was
unable to write up a description of her model.  The host was inadequate
to the task of recalling her model, but members of the audience who had
been impressed by her words last time recalled that Karen had allowed a
richer connectivity from Site to Site or from Regional to Regional in
her model.

Synthesis

Some common points arise from these models and beg some questions:

We must define a User Entity and consider how these Users, who may be
end-users or may be lower level representatives of end-users, such as
campus NOCniks; enter this system, how they interact with this system we
are defining, and how their problems are staged and addressed.
Assumptions of available tools and skills depends on who we assume the
User is.

We have to consider centralized (UCP Central) versus decentralized
(Site/Regional Entity) issues, and clearly delineate responsibilities
and interactions.  We must consider the authority of the UCP Central and
how it is derived.

We must consider the nature of the Site and Regional Entities; are they
Network Operations Centers, or Network Information Centers, or both, or
neither?  Let us call these entities Network Service Centers (NSCs) for
the moment, and withhold evaluation of what they really are.

General Discussion

Who is it that owns these facilities?  Who are the players; the
campuses, the regionals, the backbones, the commercial service
providers, etc?

How will these entities; these Users and NSCs; be coordinated?

How do we resolve problems that the participants in this model cannot
solve, such as host interoperability problems?  Are there others that
must get involved to solve these sorts of problems?

We need a means of filtering out chronic problems, ones that have been
identified, but are not yet solved, or are unsolvable by our system.



                                   2






Trouble Ticket Systems

Trouble ticket systems came up as something that seems to be an integral
part of the solution of UCPs.

Matt Mathis commented that we need a protocol for managing ownership of
trouble tickets, that we need some centralization for dealing with
problems (UCP Central), but we must have filters so that UCP Central
does not have to deal with too many routine problems.  We also need to
make sure that tickets don't ``evaporate'' and we could use a meta-UCP
protocol for evaluating how well individual UCPs were handled by the
system.  We also need to discriminate equipment failures from
infrastructure or engineering problems, which this system may not be
able to handle.  We also have to consider how the User is notified of
progress on his Ticket.

Further Synthesis

What can we glean from what everyone has said so far?

  1. We need to put a boundary around the problem; around the system we
     are trying to define.
  2. ``Users'' are outside this system boundary.  ``Network Service
     Centers'' are entities that are within the boundary of our system
     and our model.
  3. Users need a ``protocol'' or procedure for how they interact with
     this system.  Let us call this the P1 protocol; User-to-NSC.
  4. NSCs need a ``protocol'' or procedure for how they interact among
     themselves.  Let us call this the P2 protocol; NSC-to-NSC.
  5. At a minimum, we need to define what a ``User'' is, what an ``NSC''
     is, and what the P1 and P2 protocols are.  Work in this direction
     will undoubted lead to further modeling requirements.

We need to consider at least these steps in the process:

   o diagnosis of the problem
   o the resolution process
   o closure
   o connectivity versus interoperability problems

Someone described the AT&T trouble ticket model, and noted that the
person in the system that was ``closest'' to the end-user was
responsible for updating the user on progress and for closure, but that
the ticket database was centralized and centrally managed.

There was discussion of the P2 protocol and how it related to lines of
authority and contractual relationships.  There was a feeling that an
instatiation of a P2 link between two NSCs was an agreement to work
together in a certain way on UCPs.

The handling of a ticket between NSCs is bi-lateral.  Should NSCs be
certified to generate tickets?  Should they be certified to accept

                                   3






tickets?  Would one level of NSC be a ``generate only'' NSC while other
NSCs could be ``accept/generate'' NSCs?

Every contact from a User (via the P1 protocol) must be logged and
tracked by this system.  The system must be conservative, it must not
lose track of any calls (tickets) and it must reach closure on each
ticket.  What constitutes closure?  All closures must be reported back
to the User (via P1) and the User must be able to get status reports as
the User requires (again via P1).

What are the minimum capabilities of an NSC? They should include:


   o contact points (phone numbers, e-mail addresses, ...)
   o hours of operation (when can the NSC be activated?)
   o what do they do (ie, level of functionality)
   o referrals (where do they refer UCPs via P2?)
   o closure (they must be able to close open tickets via P1)
   el Chiappa             [e-mail]
       Steve Deering            [e-mail]
       Dave Forster
           Richard Fox              sytek![e-mail]
           Karen Frisa              [e-mail]
               Steve Hubert             [e-mail]
               Van Jacobson             [e-mail]
                   Stev Knowles             [e-mail]
                   Yoni Malachi
                   [e-mail]
                       Keith McCloghrie
                       sytek![e-mail]
                       Leo J. McLauglin III     [e-mail]
                           Jeff Mogul
                           [e-mail]
                           John Moy
                           [e-mail]
                               Mike Patton
                               [e-mail]
                               Drew Perkins

                               [e-mail]
                                   Stephanie Price

                                   cmcvax![e-mail]
                                   Michael
                                   Reilly

                                   [e-mail]
                                       Greg
                                       Staz

                                       [e-mail]
                                       Tim
                                       Seaver               [e-mail]

                                       Frank Slaughter          [e-mail]

                                       Richard Smith            [e-mail]

                                       Brad
                                       Strand              [e-mail]

                                       Cal
                                       Thixton              [e-mail]

                                       John
                                       Veizades


What is the role of UCP Central on routine UCPs?  Should UCP Central get
copies of all tickets from all NSCs?  Should UCP Central be primarily
mail based, as far as tracking tickets?

What is the nature of a ticket?  The ticket must be structured such that
it leads to a proper analysis of the problem.  This implies a certain
minimum of information.  Can tickets be structured to include fields, as
in a database?  Guy Almes made the point that in talking about a
distributed trouble ticket system, we are essentially trying to create a
distributed database system.  Perhaps we can glean some insight on how
to structure P2 and create a coherent distributed trouble ticket system
from distributed database design?  Can we create a trouble ticket
grammar?  Should the trouble tickets be textual, so that they can be
moved via mail, not requiring a database query language or other special
protocol?

Educating End Users

Martyne Halgren of Cornell contributed a memo to the ucp list prior to
this meeting, addressing issues regarding educating end-users, and
described NETHELP and NETLEARN tools to accomplish the education
process.  Unfortunately, the entire session needed to be devoted to a
discussion of the larger picture, and there was no time to delve into
the end-user part of the model.  Martyne's contribution was held for
follow-up discussion at a later time.



                                   4






Session Closure

The host outlined a minimum of three things that need work:


   o NSC Requirements
   o the P1 protocol
   o the P2 protocol


The host twisted arms:

Matt Mathis agreed to work on NSC requirements, the P1, and the P2
protocols.  Guy Almes agreed to work with Matt on the P2 issue.  Dan
Jordt also indicated willingness to contribute.

Follow-up discussion and postings of work in progress will be to the ucp
list ``ucp[-request]@nic.near.net''.



                                   5






ATTENDEES

    Guy Almes                 [e-mail]
    Glee Cady                 [e-mail]
    Tom Easterday             [e-mail]
    Kent England              [e-mail]
    Metin Feridun             [e-mail]
    Martyne Hallgren          [e-mail]
    Gene Hastings             [e-mail]
    Tom Holodnik              [e-mail]
    Wendy Huntoon             [e-mail]
    Dan Jordt                 [e-mail]
    Marilyn Martin            [e-mail]
    Matt Mathis               [e-mail]
    Berlin Moore              [e-mail]
    Donald Morris             [e-mail]
    Dave O'leary              [e-mail]
    Lee Oattes                [e-mail]
    Mike Patton               [e-mail]
    Marc-Andre Pepin          [e-mail]
    Paul Pomes                [e-mail]
    Karen Roubicek            [e-mail]
    Jim Sheridan              [e-mail]
    Dana Sitzler              [e-mail]
    Pat Smith                 [e-mail]
    Mary Stahl                [e-mail]
    Louis Steinberg           [e-mail]
    Allen Sturtevant          [e-mail]
    Edward Vielmetti          [e-mail]
    Carol Ward                [e-mail]
    Aileen Yuan               [e-mail]



                                   6